Software has continually increased in complexity and sophistication. Many software applications have grown to include greater amounts of functions and abilities. For example, one common application is electronic design automation (EDA), in which sophisticated design software is used to create increasingly more complex designs such as electronic component designs. The design software allows creation, viewing, and editing, and output of graphical designs and includes simulation functions. Other graphical editors allow creation of designs of many different types.
With more complex functionality, software programs can often be more prone to errors and crashes. For example, software programs such as graphical editors are prone to bugs and crash issues, and are often used in environments in which a crash may not be easily reproducible. Even if a crash is reproducible, the gathering of a reproducible testcase to facilitate debugging the software is often prohibitive due to the amount and complexity of the data to be gathered, and/or security and sensitivity issues (e.g., customers working on critical designs often do not wish to share all the technical details of their design with the software vendor).
Thus software developers have a need for sophisticated debugging tools. One common debugging tool includes tracing and logging, in which internal steps or events of execution of a program are determined using a stack trace or other tracing function, and the steps or events are stored as entries or messages in a logfile. In case of a bug or crash in the program occurring, the logfile entries can later be reviewed by a reviewer to determine the execution operations of the program leading up to the bug or crash to help diagnose the problem. However, logfiles have several limitations. While many customers or other users are willing to share these logs with a software vendor or other reviewer, it is often the case that the log contains insufficient information for a reviewer to be able to understand or reproduce the issue in order to debug it. The log can contain a trace of the low level actions performed by an interacting user of the program prior to the software crashing, but it includes no context information describing the user's input or actions leading up to the crash. It is often difficult for the reviewer to gain an understanding of what the user was trying to do, or on what type of data the user was trying to operate a particular software feature. In addition, the log typically includes a very large numbers of entries describing many different actions, which can be time consuming to review. These disadvantages limit the diagnostic capability of the logfile.